1. Field of the Invention
The present invention relates to a cache memory control circuit and a cache memory control method that control a CPU cache memory.
2. Description of the Related Art
FIG. 8 is a block circuit diagram schematically showing an entire configuration of a CPU. In FIG. 8, each of CPUs 1 and 2 incorporates a two-tier cache including an L1 cache (first cache) and an L2 cache (second cache) and is connected to an SC (system controller) 3, and the SC 3 is connected to a memory 4. In the above configuration, a cache memory control operation is performed as follows.
A move-in request issued from the L1 cache is passed through a pipeline of the L2 cache and a tag search is then performed with respect to the request data in a tag search section (tag section). When the result of the tag search is an L2 cache miss (S1), an MIB (move-in buffer) is acquired and a move-in request is issued to the SC 3 (S2). After receiving reply data from the main memory or other CPU, the SC 3 registers the data in the L2 cache, releases the MIB (S3) and transfers the data to the L1 cache (S4).
FIG. 9 is a block diagram showing a cache controller that performs the above operation. An MI-PORT 11 shown in FIG. 9 stores a new request issued from the L1 cache. An MO-PORT 12 stores a reply issued from the L1 cache to the L2 cache and move-out data sent from the L1 cache. An SC-PORT 13 is an internal resource that stores an order issued from the SC 3.
A priority section 14 feeds a command to a pipeline 15 in consideration of the superiority of each resource. In the pipeline 15, a tag search is performed with an address of the fed command by a tag search section (tag section) 16. In the case of an L2 cache hit, the data that is requested by the L1 cache is returned. In the case of an L2 cache miss, an MIB 17 is acquired and a move-in request is issued to the SC 3. At this time, information comparison is made between a current move-in request and a preceding move-in request that has been registered in MIB 3 at the same time as the issuance of the current move-in request in order to determine whether it is possible to continue processing for the current move-in request.
When an index of a succeeding move-in request and an index of a preceding move-in request correspond to each other, the succeeding move-in request is, in general, forced to wait until the MIB 17 has been released after completion of the processing for the preceding move-in request for protection of a replace block and guarantee of cache coherency. FIG. 10 shows a processing flow at this time. As shown in FIG. 10, it is determined whether an index of the succeeding move-in request and an index of the preceding move-in request that has been registered in the MIB do not correspond to each other (step S11). When the determination result is not affirmative (No in step 11), processing for the succeeding move-in request is forced to be in a standby state.
When the determination result is affirmative (YES in step S11), processing is continued and a tag search is performed (step S12). Then, depending on the result of the tag search (HIT or MISS in step S12), respective processing operations are performed.
Even when the result of the tag search for the succeeding move-in request is a cache hit, that is, even when the succeeding move-in request can actually be processed (the case where processing for the succeeding move-in request does not generate any problem), processing is forced to wait until the MIB 17 has been released. When an index of the succeeding move-in request and an index of the preceding move-in request do not correspond to each other, processing is performed based on the result of the tag search.
FIG. 11 shows a tag search method used in the tag search section (tag section) 16. In a tag search, firstly, matching is performed in an index 110 of a request address 100 to determine the corresponding block. Matching is then performed in an upper address section 120 to identify the corresponding 64-byte. FIG. 12 shows a data structure of the MIB 17. The MIB 17 includes a request address 100, a registration way and replace way 200, and other flags 300.
When the tag search section 16 has performed a tag search for the move-in request from the MI-PORT 11 and obtained the search result indicating a cache miss, the MIB 17 is acquired and the data related to the move-in request is stored in the acquired MIB 17 and a move-in request is then issued to the SC 3. A method of evacuating all replace targets to a replace buffer (MODQ) is available at this time in order to correctly reply to snoop processing due to the mismatch. However, this method uselessly obtains the MODQ resources in the case where a replace target is “clean victim” (block that has not been updated or changed and need not to be written back). Thus, a method of replying to snoop processing due to the mismatch without evacuating the replace target to a replace buffer (MODQ) and disabling a cache when the replace target is “clean victim”.
When the matching between an index of the preceding move-in request that has been stored in the MIB 17 and an index of the succeeding move-in request is performed, there may exist many succeeding move-in requests that will be forced to wait even if the search results therefor are cache hits. In order to cope with the problem, a control circuit or method that can continue processing for the succeeding move-in requests that can actually be processed is demanded.
In the above case, when the MIB 17 is acquired due to a cache miss of the preceding move-in request and an additional succeeding move-in request is issued from the MI-PORT 11, a cache hit erroneously occurs in the case where the replace target of the preceding move-in request is “clean victim”. To solve this problem, the following method has been used in the conventional art.
Firstly, states of the cache to be replaced are closely examined. When the block to be replaced is “dirty victim” (block that has been updated or changed and must be written back) at the time of occurrence of a cache miss, its tag is invalidated and data writing to the MODQ is performed. The replace data is read out from the MODQ in response to a request from the system and then written back to the memory.
Since “dirty victim” must correctly reply to the snoop processing due to mismatch even when its tag has been invalidated, “dirty victim” also holds WBA (replace address) at the MIB 17 acquisition time. As a result, when WBA of the MIB 17 and a snoop request correspond to each other even if the search result is not a cache hit, data replay is sent from the MODQ in which the replace data exists.
On the other hand, “clean victim” (block that need not to be written back and that is not invalid) is overwritten when a new cache has been registered since it need not to be written back to the memory. In this case, at the time point when a new registration has been made in a cache tag copy after the system side had received a move-in request (that is, at the time point when “clean victim” has been cleared), it is determined that there has not existed “clean victim” in the following processing. However, since it is impossible for the cache side to know the timing, “clean victim” in the cache cannot be used at the time point when a cache miss has occurred.
When a store request hits a cache in a shared state, a block type change (block type change permission) is issued to the system for the right to exclude. At this time, since a block should not be shared in a store operation, a succeeding request is forced to wait until the store operation has been executed for guarantee of cache coherency even if the succeeding request hits a shared cache of the same block as that a preceding store request has been made for.
In the system having the above configuration, when continued processing does not generate any problem even in the case where an index of a succeeding move-in request and an index stored in the MIB 17 match with each other, it is determined whether a move-in operation can be performed depending on the cache state at the time of a cache hit so that processing can be continued. The flow at this time is shown in FIG. 13. Since “dirty victim” is supposed to have been invalidated at the cache miss detection time, when a dirty block has been hit (step S21), it can be determined that a way that is entirely different from a way of a preceding request in the MIB is targeted, with the result that processing can be performed. Therefore, only in the above case (YES in step S21), it is possible to continue processing for the succeeding move-in request whose index has corresponded to the index stored in the MIB. In the case where a clean block has been hit, it is impossible to determine whether a move-in operation can be performed for the above reason, so that processing cannot be continued.
As a reference of the related art, Japanese Patent Laid-Open No. 2002-229852 is known.
In the case of a cache hit to a clean block, when the clean block is the clean victim of a preceding move-in request or that has been obtained due to an application of block type change, it is impossible to continue processing. On the other hand, any problem does not occur when processing is performed for clean blocks other than the above case. However, in the conventional art, determination is made based on a tag in some cases, so that it is impossible to determine the above case. As a result, succeeding processing operations are collectively forced to wait until the MIB has been released.
Further, the determination is made based on the result of a tag search as described above, which requires time to read out the result and involves activation of additional processing or ensuring of resources temporarily. As a result, the processing for other requests may be interrupted.